-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add PULUMI_STACK for compiler run enviroment #578
Conversation
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution! This seems reasonable to me at a glance. Ideally we would also have a test showing that this works.
Also curious if others from @pulumi/platform or @AaronFriel have any opinion on this, or other suggestions of how to implement this.
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
Regarding a test ... I'm not sure where and how to ideally implement such a test. Would be an acceptance test unless we can mock the Any thoughts or ideas on this @tgummerer |
I think an integration test would be fine here, maybe creating two different stacks with different outputs based on the environment variables you are introducing here? |
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
@tgummerer I'm having a hard time setting up the integration tests to run locally. Obviously Pulumi is not using my updated binary as language plugin. So my changes don't have any effect during the test. Is there a doc or could you give me a hint on how to run them locally. I already pushed an unfinished test PTAL. Installing the binary will give me an error:
|
/run-acceptance-tests |
Please view the results of the PR Build + Acceptance Tests Run Here |
How exactly were you trying to install the binary? I believe you should be able to run |
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
Thanks! It was indeed a PATH issue having both Pulumi from source and Brew in place. I finished/fixed the test, fingers crossed it'll pass now. |
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
/run-acceptance-tests |
Please view the results of the PR Build + Acceptance Tests Run Here |
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
/run-acceptance-tests |
Please view the results of the PR Build + Acceptance Tests Run Here |
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
/run-acceptance-tests |
Please view the results of the PR Build + Acceptance Tests Run Here |
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
…d `PULUMI_CONFIG` as environment variable to compiler process
PR is now waiting for a maintainer to take action. Note for the maintainer: Commands available:
|
/run-acceptance-tests |
Please view the results of the PR Build + Acceptance Tests Run Here |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you again, and thanks for the patience while we worked out the best way to also make this backwards compatible.
I'm gonna leave this PR open until tomorrow just in case anyone else has any comments, but this looks good to me!
That went really smooth, kudos and big thanks to you! |
This PR adds a new environment variable
PULUMI_STACK
to the compiler run.The possibility to determine the stack from the compiler makes it a lot more flexibel when dealing with stack specific resources.
Here an example (I'm using Jinja2 though the issue itself is not compiler specific):
A more complex scenario would be to add HA resources to a production stack where an integration system is zonal set up to reduce cloud costs.
My approach seems a bit naive to be honest, but I couldn't figure out a better way without breaking interfaces. Also this solution only works from the
Run
-call context, soGetRequiredPlugins
might not be accurate when plugins are stack specific.WDYT?